From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  1 09:33:16 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id JAA23768
	for <lyris.aprsspec@tapr.org>; Sun, 1 Apr 2001 09:33:15 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 1 Apr 2001 10:31:46 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS Compliance
In-Reply-To: <LYR11586-4013-2001.03.31-14.22.50--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-4154-2001.04.01-09.49.27--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104011027380.12217-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sat, 31 Mar 2001, Jeff King wrote:

> 2. Who are the present active members?

The current members ar:
     John Ackermann <jra@febo.com>
     Bob Bruninga <bruninga@nadn.navy.mil>,
     Keith Sproul <ksproul@rci.rutgers.edu>,
     Mark Sproul <msproul@apmail.ap.org>,
     Brent Hildebrand <BHildebrand@earthlink.net>,
     Mike Musick <mcmusick@anet-stl.com>
     Stan Horzepa
     Steve Dimse  - Resigned

     Roger Barker, (UIview) invited but declined due to other priorities
     Dale Heatherington (APRSd) invited but declined

Bob
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You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  1 13:48:31 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA13965
	for <lyris.aprsspec@tapr.org>; Sun, 1 Apr 2001 13:48:28 -0500 (CDT)
Mime-Version: 1.0
X-Sender: msproul@mailbox.arn.net
Message-Id: <LYR11589-4191-2001.04.01-14.04.42--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 1 Apr 2001 13:48:13 -0500
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: MLSproul <msproul@arn.net>
Subject: [aprsspec]  Re: APRS Compliance
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <p04330100b6ed25cc4602@[204.254.145.106]>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk


I am in the process of making some text compliance files.These will
be a series of files and will probably be released as each is
completed and verified.


Maury
-- 

______
M. L. "Maury" Sproul, PE                                  | 806-354-0306
Amarillo, TX
msproul@arn.net
W5UGQ

---
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To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  1 14:19:28 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA15869
	for <lyris.aprsspec@tapr.org>; Sun, 1 Apr 2001 14:19:25 -0500 (CDT)
Message-Id: <LYR11589-4201-2001.04.01-14.35.43--lyris.aprsspec#tapr.org@lists.tapr.org>
Subject: [aprsspec] Re: APRS Compliance
Date: Sun, 1 Apr 2001 15:19:11 -0400
x-sender: sdimse@earthlink.net
From: Steve Dimse <k4hg@tapr.org>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <200104011919.MAA19284@gull.prod.itd.earthlink.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On 4/1/01 10:31 AM Bob Bruninga (bruninga@usna.edu) wrote:

>     John Ackermann <jra@febo.com>
>     Bob Bruninga <bruninga@nadn.navy.mil>,
>     Keith Sproul <ksproul@rci.rutgers.edu>,
>     Mark Sproul <msproul@apmail.ap.org>,
>     Brent Hildebrand <BHildebrand@earthlink.net>,
>     Mike Musick <mcmusick@anet-stl.com>
>     Stan Horzepa
>     Steve Dimse  - Resigned
>
There is also a TAPR slot, occupied by Greg Jones.

Steve K4HG
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Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  1 14:36:48 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA17304
	for <lyris.aprsspec@tapr.org>; Sun, 1 Apr 2001 14:36:44 -0500 (CDT)
Mime-Version: 1.0
X-Sender: ksproul@vger.rutgers.edu (Unverified)
Message-Id: <LYR11589-4207-2001.04.01-14.52.56--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 1 Apr 2001 15:32:39 -0400
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: Keith Sproul <ksproul@vger.rutgers.edu>
Subject: [aprsspec] Current Members
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <a0501044cb6ed32c12480@[165.230.133.70]>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Mark's Sproul address is:

	msproul@jove.rutgers.edu

The address listed for Keith Sproul is okay, but I would prefer:

	ksproul@vger.rutgers.edu

Keith

-- 
Keith Sproul			Ham Radio WU2Z
ksproul@vger.rutgers.edu	732 821-4828
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  1 16:09:58 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA25749
	for <lyris.aprsspec@tapr.org>; Sun, 1 Apr 2001 16:09:53 -0500 (CDT)
Date: Sun, 01 Apr 2001 17:09:25 -0400
From: John Ackermann   N8UR <jra@febo.com>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS Compliance
Message-ID: <LYR11589-4232-2001.04.01-16.26.08--lyris.aprsspec#tapr.org@lists.tapr.org>
In-Reply-To: <LYR11592-4201-2001.04.01-14.35.43--n8ur#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <2597454516.986144965@[192.168.1.26]>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk



--On Sunday, April 01, 2001 3:19 PM -0400 Steve Dimse <k4hg@tapr.org> wrote:

> On 4/1/01 10:31 AM Bob Bruninga (bruninga@usna.edu) wrote:
>
>>     John Ackermann <jra@febo.com>
>>     Bob Bruninga <bruninga@nadn.navy.mil>,
>>     Keith Sproul <ksproul@rci.rutgers.edu>,
>>     Mark Sproul <msproul@apmail.ap.org>,
>>     Brent Hildebrand <BHildebrand@earthlink.net>,
>>     Mike Musick <mcmusick@anet-stl.com>
>>     Stan Horzepa
>>     Steve Dimse  - Resigned
>>
> There is also a TAPR slot, occupied by Greg Jones.
>
> Steve K4HG

Greg resigned as the TAPR representative.  I remain in the non-voting 
moderator slot, and have been speaking, but not voting, for TAPR in the 
interim.  TAPR will be appointing a new representative to replace Greg.

John
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From bounce-aprsspec-11589@lists.tapr.org  Sat Apr  7 16:20:14 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA14288
	for <lyris.aprsspec@tapr.org>; Sat, 7 Apr 2001 16:20:14 -0500 (CDT)
Message-ID: <LYR11589-5499-2001.04.07-16.36.34--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sat, 07 Apr 2001 17:18:09 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] APRS(tm) protocol allows for BEACONet variant
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3ACF8411.31D2EA70@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Now that the dust has settled on the "Protocol Compliance" thread (did
anyone actually volunteer to do anything? <grin>), I wanted to be a "man
of my word" and move the discussion of the BEACONet protocol here (at
least the one that started on TAPR's APRS(tm) listserve).

I'll get right to the point: for those who choose to take the time to
understand and research before expressing an opinion, they will find
that BEACONet fits quite nicely into the existing APRS(tm) paradigm.

The BEACONet system was developed in such a way as to function in
compliance with the APRS(tm) AltNET concept.  Here's ALTNET's are:
http://www.dididahdahdidit.com/text/altnets.txt

  As an aside...APRSdos *will* decode BEACONet transmissions 
  simply by invoking the following command: CONTROLS-FILTERS-OTHER
  to ON.  This is noted at:
  http://www.dididahdahdidit.com/text/protocol.txt

  Additionally, UI-View works for both BEACONet and APRS operation
  without needing to invoke/revoke any filtering.

According to the APRS Protocol Specification 1.0.1 (a 3MB file at
ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf):
Page 23 of 128...
"Generic APRS   APRS uses the following generic beacon-style
  Destination   destination addresses:
    Addresses   AIR*  ALL*   AP*   BEACON  CQ*     GPS*   DF*
                DGPS* DRILL* DX*   ID*     JAVA*   MAIL*  MICE*
                QST*  QTH*   RTCM* SKY*    SPACE*  SPC*   SYM*
                TEL*  TEST*  TLM*  WX*     ZIP*
                The asterisk is a wildcard, allowing the addresss to
                be extended (up to a total of 6 alphanumeric
                characters)."
Page 25 of 128...
"ALTERNATE NETS  Any other destination address not included in
                 the specific generic list or the other categories
                 mentioned above may be used in ALTERNATE NETS
                 (ALTNETs) by groups of individuals for special
                 purposes."

A typical BEACONet frame looks like this:
W2EV>HY1G02-15:[FN03XD] w2ev@arrl.net
     ^^^^^^ ^^
     |
     This makes the frame look like an ALTNET to APRS software.

So...BEACONet stands as it originally was...an application of UI-Frame
technology that:
* can use APRS(tm) software (but doesn't have to)
* operates within the APRS(tm) spec as an ALTNET
* allows for experimentation and expansion on that spec without
  destroying it

If you think of APRS(tm) as being "Major League Baseball", then think of
BEACONet as being "the farm club".  Just don't go "calling up" any of
the stuff we're developing without being prepared to trade us back
enough to make it worth our while. :o)

Back to having fun...ya know...the eta-Aquarids meteor shower is just
around the corner...and the spring/summer Tropo season is forming;
anyone want to actually generate some RF? :o)

With a smile and a wink,
Ev Tupis, W2EV
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From bounce-aprsspec-11589@lists.tapr.org  Sat Apr  7 18:05:26 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id SAA19824
	for <lyris.aprsspec@tapr.org>; Sat, 7 Apr 2001 18:05:25 -0500 (CDT)
Message-ID: <LYR11589-5505-2001.04.07-18.22.00--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sat, 07 Apr 2001 19:03:37 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] APRS TOCALL-SSID Help, please
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3ACF9CC9.8C477566@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

According to the APRS Protocol Specification:
(pg 23/128):  "In all of these cases, the Destination Address SSID may
specify a generic APRS digipeater path."

(pg 25&26/128): A chart describing the "Generic Digipeating" noted
above.

Yet, when I launch a frame which includes this information, it is
ignored by all of the APRS digi's around me (even though I'm LOS to at
least three WIDEn-N digis).

My APRS frame looks like this:
W2AAA-2>APW248-3:=4310.21N/0 . . .
            ^
            This infers WIDE3-3 from the protocol spec

Am I missing something about the use of this function?

Ev, W2EV
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To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
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From bounce-aprsspec-11589@lists.tapr.org  Sat Apr  7 18:10:14 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id SAA20000
	for <lyris.aprsspec@tapr.org>; Sat, 7 Apr 2001 18:10:12 -0500 (CDT)
Message-ID: <LYR11589-5508-2001.04.07-18.26.35--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sat, 07 Apr 2001 19:07:59 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS TOCALL-SSID Help, please
References: <LYR21978-5505-2001.04.07-18.22.00--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3ACF9DCF.4DB231DB@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Correction...

My APRS frame looks like this:
W2AAA-2>APW248-3:=4310.21N/0 . . .
               ^
               This infers WIDE3-3 from the protocol spec

Yet, this is ignored by the WIDEn-N digi's in my area.  Am I overlooking
something about the use of this function?

Ev, W2EV

---
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From bounce-aprsspec-11589@lists.tapr.org  Sat Apr  7 20:13:22 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id UAA28463
	for <lyris.aprsspec@tapr.org>; Sat, 7 Apr 2001 20:13:20 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sat, 7 Apr 2001 21:13:07 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS(tm) protocol allows for BEACONet variant (fwd)
Message-ID: <LYR11589-5520-2001.04.07-20.29.52--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104072111520.15990-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Your use of different TOCALLS for everyone in BeacoNET is not a fixed
string, thus it is not an ALTnet.  Thus no Kenwood D7, or D700 user can
listen in because the ALTnet which  they might set iaw  the APRSspec won't
match but one user at a time.  Thus, you exclude probably 10,000 users
from monitoring your Beacon Net while traveling.  Such exclusion to save
one byte seems awfully drastic.  More comments at end...

On Sat, 7 Apr 2001, Ev Tupis wrote:

> The BEACONet system was developed in such a way as to function in
> compliance with the APRS(tm) AltNET concept.  Here's ALTNET's are:
> http://www.dididahdahdidit.com/text/altnets.txt

> According to the APRS Protocol Specification 1.0.1 (a 3MB file at
> ftp://ftp.tapr.org/aprssig/aprsspec/spec/aprs101/APRS101.pdf):
> Page 25 of 128...
> "ALTERNATE NETS  Any other destination address not included in
>                  the specific generic list or the other categories
>                  mentioned above may be used in ALTERNATE NETS
>                  (ALTNETs) by groups of individuals for special
>                  purposes."
 
> A typical BEACONet frame looks like this:
> W2EV>HY1G02-15:[FN03XD] w2ev@arrl.net
>      ^^^^^^ ^^
>      This makes the frame look like an ALTNET to APRS software.

Yes, but only people who set their ALTnet to "HY1G02" will see it.  If
any letter changes, then it is a different ALTnet and will not be decoded 
by anyone operating IAW the Spec.

Yes, someone can set thier ALTnet to HY1G02, but he will only receive
packets from that station only.  Not anyone else in Beacon net unless
the station is identical in Power, Antenna, HAAT, Direction and Gain.

But there is no way for an ALTnet compliant APRS station to receive a
packet from any other combination, without changing their entry..  Or
disabling ALTnets entirely.

Bob





---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sat Apr  7 20:16:00 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id UAA28548
	for <lyris.aprsspec@tapr.org>; Sat, 7 Apr 2001 20:15:57 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sat, 7 Apr 2001 21:15:45 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS TOCALL-SSID Help, please 
Message-ID: <LYR11589-5521-2001.04.07-20.32.31--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104072114100.15990-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

This SSID DIgipeating feature was put in the Spec for the next generation
of APRS (so that everything would be backward compatible when we moved to
APRS Phase III.
It allows HOPS of up to 7 HOPS using the WideN-N protocol, but saves 7
bytes per packet by eliminating the DIGI field entirely... and only using
the SSID as the number of hops. 

I think only DIGIned and UIdigi and the other new digi codes support it
yet.  The Kenwood D700 digi mode also does... (hummh, I forget.  Ill have
to look up how to do this)...   Bob

Apr 2001, Ev Tupis wrote:

> According to the APRS Protocol Specification:
> (pg 23/128):  "In all of these cases, the Destination Address SSID may
> specify a generic APRS digipeater path."

> Yet, when I launch a frame which includes this information, it is
> ignored by all of the APRS digi's around me (even though I'm LOS to at
> least three WIDEn-N digis).
> 
> My APRS frame looks like this:
> W2AAA-2>APW248-3:=4310.21N/0 . . .
>             ^
>             This infers WIDE3-3 from the protocol spec
> 
> Am I missing something about the use of this function?
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From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: APRS TOCALL-SSID Help, please
References: <LYR21978-5521-2001.04.07-20.32.31--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
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X-Message-Id: <3ACFC748.E57AF64A@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Bob Bruninga wrote:
> This SSID DIgipeating feature was put in the Spec for the next
> generation of APRS (so that everything would be backward 
> compatible when we moved to APRS Phase III.

Gotcha.  That explains why no one processed it.  What's the plan for
this feature?  One would think that it ought to be supported by
stand-alone digi's if it's going to be effective.  Is there a movement
afoot to get TNC firmware to support it?

Ev, W2EV
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Ev Tupis wrote:
> 
> Now that the dust has settled on the "Protocol Compliance" thread (did
> anyone actually volunteer to do anything? <grin>),

Ev:

Yes, at least according to what I saw on here, 12 people had volunteered.
However, it appears volunteers were not what was required (even though the old
WG had requested them.... go figure?).    Two people
(outside of these volunteers) were asked to join the WG, and they both declined.
Hence the spots still remain open and no direction or next step (at least published)
has been set. So your guess is as good as mine.

It has been said, that if you do something, and submit it to the WG (this list?)
some action will be taken. It has not been my personal experience this is the case, hence
my feelings they had ceased to exist as a viable body. Granted, my contribution had been 
minor, but I am reluctant to make major contributions (to a spec document) with no
feedback or in a vacuum, as had been suggested the current mechanism is. I suspect lacking 
such direction or feedback, the previous statement would apply to others as well. 

My impression here is to just do what you want.... if you get sufficient user support it will
be adopted via assimilation. A spec document is not a spec document without a compliance
mechanism. So, your best bet here is just to get some user support for your BEACONNet
extension, and write your own spec. Approach some of the authors requesting support
for it (most seem more then happy to do this) and have at it. As to the entrenched incumbents
such as Kenwood, I suspect if you get sufficient interest, they will adopt it. Not sure
if BeaconNet is compatible with DX Clusters, but if not, you might consider this. The DX'ers,
as a group, are not afraid to spend money. This is a language Kenwood understands.


Good luck

Jeff
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X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
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On Sat, 7 Apr 2001, Ev Tupis wrote:

> Bob Bruninga wrote:
> > This SSID DIgipeating feature was put in the Spec for the next
> > generation of APRS (so that everything would be backward 
> > compatible when we moved to APRS Phase III.
> 
> Gotcha.  That explains why no one processed it.  What's the plan for
> this feature?  One would think that it ought to be supported by
> stand-alone digi's if it's going to be effective.  Is there a movement
> afoot to get TNC firmware to support it?

SO far we have only seen Digined and UIdigi and maybe some others?  No, no
big movement.  For a closed net where someone has hundreds of mobiles and
only a few digis, it really shortens packets and allows more users.

bob
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In trying to find an APRS compliant protocol to do all the BeaconNet needs
while still being SPEC compliant (and receivable on a Kenwood), I came up
with this:

W2EV-xx>CQxxxx,HOP2-2:>GG##ggXX........

It gives at least 7 bytes worth of special BEACONet information and
the total cost is only ONE (1) more byte than the existing BeaconNet
format.  Here is how:

*  FROM call SSID for one byte (1 of 16) or 2 bytes (1 of 10 & 1 of 5)
*  In the TOcall, you can use 4 bytes (1 of 36 each)
*  In the GRID square report, you get 2 bytes
   The first one (the TABLE or OVERLAY character can be 1 of 36
   The second one (the ICON) can be one of about 90

These 7 or 8 bytes can convey a lot of info...
This is the preferred Gridsquare report format as written in the spec.

So I think that this format would give you a very powerful format for
BEACONet packets that could be received by anyone, this  includes:

1) Newbees who have no clue how APRS or anything else works, but if they
tune to BEAOCNnet, they will see something without having to know "how" to
set up their APRS software...

2) Kenwood mobile operators (remember the D700 tunes 6m, 2m, 220, 440, 900
and 1296 bands)...

3) Kenwood backpackers and QRP operators with only their HT's...

Although it would be nice to use ICONs that are meaningful, I don't care
at all if you use any of the 90 icon symbols to mean anything  you want in
BEACONet.  That is the kind of flexibiilty that APRS should be able to
afford...  And there are some un-used ICON definitions that we could
possibility consider if you find that defining one or two more might make
things really neat...

And the OVERLAY characters can be applied to ANY ICON, so it can be
considered as a completelly independent byte...  again, though, it would
be nice if it made visual sense in most cases...

Anyway, just an idea to let you get lots of info in a standardized way, 
into the shortest packet and still be receivable on all APRS stations.

 de WB4APR@amsat.org, Bob
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Wait wait.  Please don't draw conclusions prematurely by inferring that
a one byte space-saving is the sole reason behind the desire for
BEACONet frames to be treated as an ALTNET.  That is not correct.  There
are *many* reasons for doing so (I'll address them in a future eMail if
this is a point that needs clarifying).  Let's take one thing at a time.

Your reply hit the following topics:
* Kenwood D7 and D700 don't have the ability to disable ALTNET
  filtering and therefore would be blind to this variation of the
  BEACONet protocol
* A BEACONet TO-Call of "HY1G02-15" is a specific ALTNET unto itself
  and you said, "... only people who set their ALTnet to 
  "HY1G02" will see it.  If any letter changes, then it is a 
  different ALTnet and will not be decoded by anyone operating IAW 
  the Spec."

The flippant response to the second item would be "gee...you built-in
the ability to turn off ALTNET filtering into APRSdos, why didn't you
tell Kenwood to do the same thing?" :o)  <-really intended as humor, not
a flame...it's really nice that the filter-off function is in APRSdos.

  - you know that APRSdos *will* decode BEACONet by turning
    off filters, and so will UI-View (natively, without the need
    to mess with anything).  WinAPRS won't . . . but that's because
    it doesn't appear to follow the ALTNET spec at all...period.
  - since the BEACONet TO-Call information appears to work on two
    major APRS software titles, the discussion turns to the Kenwoods

*** The rest of this includes interests of the BEACONet community ***
*** and is a bit lengthy.  Please read it to get a better insight ***
*** to the interests that are being addressed, rather than simply ***
*** assuming that APRS(tm) interests are one-size-fits-all.       ***
*** In a nutshell the text below will discuss:                    ***
***  + The dilema of "backwards compatibility"                    ***
***    - A contrast of APRS and BEACONet digipeating needs as an  ***
***      example of a tough decision that is related to the dilema***
***  + The need to include certain information in the TO-Field    ***
***    in order to meet the needs of the BEACONet community       ***
***    - A very good reason it should be in the TO-Field, from    ***
***      perspective of BEACONet operation                        ***

As for the D7 and D700 implementation... this is a variation of a larger
issue: how much "backward compatibility" does one offer when developing
new systems?  This is a tough one to put one's arms around...especially
when the "old stuff" is still being actively marketed.  There is a fine
line between a manageable leap in technology and an unmanagable one (one
wonders if OS/2 would have been more successful, had IBM sat on it until
now -- but I digress).  :-)

This is the same issue that had to be delt with when determining just
how important it was to use *only* TRACEn-N digipeating (exclusively) in
the BEACONet service.  That would mean that only Kantronics KPC-model
TNC's with ROM 8.2 or above could be used for stand-alone digi's (though
I've been told that the new UIDIGI firmware may support it now).

Given that tracing RF paths is a core BEACONet need, the decision was
made to do just that.  We couldn't take the risk of someone putting a
non-call substituting, channel-flooding alias on the frequency (imagine
even an inadvertant WIDE,WIDE,WIDE in a world-wide collision
domain...ouch!).

So...back to the limitations of the D7 and D700.  If BEACONet-ers used
the (very valid) variation of the protocol that started with CQ, instead
of HY, I'm hearing that they would be able to decode the packet
correctly (even though [GR##ID] is marked as obsolete in the spec?)?

Then the question becomes...how important is "HY" to a BEACONet frame
(W2EV>HY1G02-15:[FN03XD] w2ev@arrl.net)?  HY is a frequency designator. 
H=HF (3-30 MHz) and Y=the 26th segment from 3-MHz (the scale runs
0,A,B,C,D,...Z) which is 28-MHz -- in this case.  Launching a BEACONet
frame as CQ1G02-15 is fully allowed in the APRS spec (and allowed in the
BEACONet spec), but there would be a loss of "band-of-origination"
information.

Here is the thought-tree on this topic:
* The long range hope is that BEACONet will take on a following 
  of it's own with an audience that may not necessarily be APRSers
  today (DXers and contesters)
* It would be advantageous to establish an APRServ-like Internet
  service in the near future (maybe AHost?)
* There is no frequency-of-origination flag in the APRS protocol
  specification and no way to seperate frames by frequency once
  they are collected by APRServ...so all frames go on the same map
* A screen full of icons on a map means very little to the BEACONet
  service if band-information can't be parsed out (hmmm...which band
  is responsible for the propagation? <smile>)

At this stage of BEACONet experimentation...I'd say that the answer is
"yes", it *is* important to embed frequency in *every* transmission;
even if that leaves "10,000" D7/D700 users out of the loop for decoding
the transmissions of others.  They bought their transceivers for
APRS...which is where they will continue to work.

Given that the TO-FIELD goes out with 7-bytes consumed whether you use
them all or only "CQ" (that's the AX.25 spec), putting it there seems to
make a ton of sense.

Of course, this all may change by the time this BEACONet stuff either
matures or fizzles out entirely.

Well, I've started and stopped this eMail several times and it's now
midnight.  I hope it didn't come though as too choppy.  I'm going to
bed.  The twins wake up at 7 without regard as to how late I stay up. 
:o))  Thanks to anyone who decided to take the time to read through this
eMail and understand the interests being addressed.

Ev
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Bob Bruninga said:
> In trying to find an APRS compliant protocol to do all the 
> BeaconNet needs while still being SPEC compliant (and 
> receivable on a Kenwood), I came up with this:
> 
> W2EV-xx>CQxxxx,HOP2-2:>GG##ggXX........

(( by the way, before I Bob's email in full perspective ... neither
"band of origination" nor "antenna pointing vector" information appears
to be contained in the suggestion above...so it hardly begins to meet
"all the BeacoNet needs"))

Bob is sharing a note with the listserve that he shared with me
privately last week -- and I replied to.  I'm saddened that he did so,
as I'd have preferred to not air this topic to the list.  Unfortunately,
the note can't go unreplied to.

My reply to him included "human engineering" issues that included *two*
times during the development of BEACONet in which I attempted to keep up
with a spec that changed just as I reached a publication deadline and
the discouragement that it engendered.

  - "Space Mode" used to exist in APRS-dom.  When invoked, the grid 
    was placed in the To-Field to save transmission time (hmmm...the 
    same reasons for BEACONet's wanting to do it that way).

    Just as I was going to roll this out for PropNET (as BEACONet
    was called back then)...the spec changed to antiquate it in 
    favor of [GG##gg] in the comment field.

  - I quickly re-wrote the article that I was working on (QST of
    November 1999) and resubmitted it for publication.  This was
    no small task...as anyone who has ever written an article
    knows...and inadvertantly left out a very important item that
    proved to be devastating (FULLDUP ON for for Meteor Mode in a
    manually-configured WinAPRS Leonids station) as a result of the
    rush to rewrite.  Bob later wrote to the listserve something
    about "maybe next time the meteor effort could be better done".
    arghhhhhhh!

    Discouraged from the work that had to be redone, I took some
    time to "regroup" around the new concept of [GG##gg] and
    continued developing.

  - [GG##gg] is no longer in favor, but it is now >GG##ggxxx....
    Oh...my...gawd!  Guess what?  Watch out for May's QST...it's 
    already gone to press. (I'm leaving out a lot of detail of
    my conversation with him and the wg around getting them to 
    *not* abandon [GG##gg], by the way)

I've done my best to follow this APRS moving target, but at some point
I've got to say "enough is enough".  BEACONet is a cousin to the APRS
service.  The APRS spec shows [GG##gg] as obsolete, and the BEACONet
service has adopted it.  Get over it for now and move on.

If the APRS service wants BEACONet to be fully compliant, then someone
is going to have to work to address the issues of the BEACONet service
-- as a user of the BEACONet service...not through the eyes of the APRS
service as the two services have different needs.

Until then, authors of software that decodes UI-frame packets are
encouraged to build-in BEACONet parsing of To-Field information and reap
the rewards of marketing to a whole new group of UI-Frame packet users
to which the APRS service does not cater.

Evhen Tupis, W2EV

I'm going to bed...maybe the morning light will melt the grumpies away.
:o)
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On Sun, 8 Apr 2001, Ev Tupis wrote:

> Please don't draw conclusions that a one byte space-saving is the sole
> reason behind the desire for BEACONet frames to be treated as an ALTNET.

I have shown how you can fit all of the same data in a fully APRS spec
compliant packet and it only takes one more byte, so the conclusion seems
inescapable?

>   - since the BEACONet TO-Call information appears to work on two
>     major APRS software titles, the discussion turns to the Kenwoods

Yes, two out of say a dozen?

> *** In a nutshell the text below will discuss:                    ***
> ***  + The dilema of "backwards compatibility"                    ***
> ***  + The need to include certain information in the TO-Field    ***

I see no reason why it must be in the TOfield and make the packet
non-APRS compliant when there are other places to put it.

> For the D7 and D700... how much "backward compatibility" do [we need?]
> If BEACONet.. started with CQ, instead of HY,... they would be able to
> decode the packet...    [but loose all "frequency Band information"]
> Then the question becomes...how important is "HY" to a BEACONet frame
> (W2EV>HY1G02-15:[FN03XD] w2ev@arrl.net)?  HY is a frequency designator. 

put it in one of the other 8 "free" bytes I pointed out in my proposed
solution.  There are all kinds of places to put it...

> * There is no frequency-of-origination flag in the APRS protocol

Each packet has as many free bytes as you want.  One can put anything in
any of the free bytes in any APRS packet.  Anyone can decode them to mean
anything they want... without violating the spec.  I am all for adding
such a designation for this application, but just not in a place that
makes the packets non-compliant.

> * A screen full of icons on a map means very little to the BEACONet
>   service if band-information can't be parsed out (hmmm...which band

The BAND information and sub-band information should go in the ICON and
OVERLAY characters.   Then a quick glance at any BEACONnet map would
instantly convey that information.   Here's how:

Choose as many ICONS as you need for all of the bands (there are 90).
THen use the 36 overlay characters for the sub-band.  ANy author then that
supports BeeacoNET would parse out BAND and FREQ info from those bytes and
do anything you want with them.  The ICONS dont have to make sense.  Its
just that those bytes are "free" to use for conveying this information.

* At this stage of BEACONet experimentation...I'd say that the answer is
* "yes", it *is* important to embed frequency in *every* transmission;

And I agree 200%.  Just dont put it in a place where it violates the spec
and makes BEACONet non-compliant with APRS and locks out thousands of
users.
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 07:57:32 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id HAA20425
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 07:57:24 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 08:57:12 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: The moving target [was:A BeaconNet idea...]
In-Reply-To: <LYR11586-5542-2001.04.07-00.55.05--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5596-2001.04.08-08.14.00--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104080840190.22788-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sun, 8 Apr 2001, Ev Tupis wrote:

> > In trying to find an APRS compliant protocol to do all the 
> > BeaconNet needs while still being SPEC compliant (and 
> > receivable on a Kenwood), [Bob] came up with this:
> > 
> > W2EV-xx>CQxxxx,HOP2-2:>GG##ggXX........

> Neither "band of origination" nor "antenna pointing vector" information
> appears to be contained in the suggestion above...so it hardly begins to
> meet "all the BeacoNet needs"))

Huh?  There are 8 bytes you can do anything with! and I listed them.
in my original proposal:

   xx   in the FROM call
   xxxx in the TOCALL
   XX   in the Grid format.  <== This is where I would put FRQ/BAND info

> Bob is sharing a note with the listserve that he shared with me
> privately last week -- and I replied to.  I'm saddened that he did so,
> as I'd have preferred to not air this topic to the list....

I thought we brought this to the APRSspec list for open discussion?
It was a message I sent to you.  Not one you sent to me.  So I dont think
it is any violation of etiquette to re-post my suggested format here...

Ev, you seem to think I am working against you.  Far from it.  I LOVE the
BeacoNET concept and am more than willing to do anything I can to make it
popular and a great service.  To that end, I am trying to help make sure
it is decodable by everyone, not just the few people who go out and get
special software...

You mentioned the QST article as the main reason why you dont want to
change.  Yet only 2 authors currently support BeaconNET (and I am one
of them).  This raises some interesting points if you did change to an
APRS compliant format at some time in the future:

1) Both those authors would release a new version overnight.  End of
problem.

2) ALL other existing APRS software would instantly be BEACOnet capable...
End of problem.

3) All Kenwood mobiles would be able to monitor BeacoNET anytime,
anywhere...  End of problem.

Bob
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 08:38:01 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id IAA22615
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 08:37:59 -0500 (CDT)
Message-ID: <LYR11589-5602-2001.04.08-08.54.26--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 09:35:58 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Other BEACONet interests to factor [was:D7/D700 and ALTNET [was:APRS(tm)  Protocol]]
References: <Pine.GSO.4.05L.10104080806180.22788-100000@arctic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD0693E.D7ACA0D3@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Bob Bruninga wrote:
> > Please don't draw conclusions that a one byte space-saving is 
> > the sole reason behind the desire for BEACONet frames to be 
> > treated as an ALTNET.
> 
> I have shown how you can fit all of the same data in a fully APRS
> spec compliant packet and it only takes one more byte, so the 
> conclusion seems inescapable?

ok...I'll explain it again...

If one is truly interested in finding a good solution to your dilema,
then one will need to take the time to understand the broader BEACONet
interests and address them too.  As with any system, items become
interrelated.  One cannot simply offer a solution to one item and walk
away, as it may introduce other problems elsewhere.  That is the case
here.

An additional related item is described here:
http://go.to/BEACONet | Information | Contest and RadioSport Use

As one reads over the information, key-in on the last item in the
information chart.  BEACONet enjoys an alias called RFONLY (although it
isn't expressed within that text...the concept is).  It is an explicit
instruction to not IGate (remember...it's *not* about privacy).  UI-View
processes the alias correctly and APRSdos doesn't IGate (yet another
reason why both of these titles are supported in the BEACONet world).

By taking BEACONet out of the world of the ALTNET something else
happens:
* RFONLY becomes an issue because now all other APRS programs can
  decode it a BEACONet frame...and they don't recognize the RFONLY
  alias

The astute observer will have two comments:
    "No one can guarantee that some third party won't IGate a 
     signal anyway, even with the alias"
    "It's not the contesters' fault if someone else relays the
     information"

As for the first statement...while that is true, the chances of it
happening are _significantly_ reduced by using a system that is
primarily supported by products that behave as needed (an analogy would
be the fact that I can write software to digipeat a frame, even if it
does not contain a digipeat alias...but no one does).

As for the second statement...Dan Henderson (Contest Manager at the
ARRL) has come right out and said "the use of packet is prohibited"
(exact quote) in ARRL VHF contests.  It took _considerable_ effort to
educate him that DXCluster Spots are different than is simplex,
non-digipeated UI-Frame packet.  Even then, I'm not sure he truly got
it.  I'm not willing to introduce other software that ignores RFONLY,
given that history.

So...back to my original statement:
> > Please don't draw conclusions that a one byte space-saving is 
> > the sole reason behind the desire for BEACONet frames to be 
> > treated as an ALTNET.

Here's another.  Help us to find a win-win solution.

By the way...I'm subscribed to the list...there's no need to cc: the
thread to me directly, too.

Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 08:48:50 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id IAA22949
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 08:48:46 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 09:48:32 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: The moving target [was:A BeaconNet idea...]
In-Reply-To: <LYR11586-5542-2001.04.07-00.55.05--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5603-2001.04.08-09.05.20--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104080923000.23360-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sun, 8 Apr 2001, Ev Tupis wrote:

Bob Suggested:
> > W2EV-xx>CQxxxx,HOP2-2:>GG##ggXX.Z......
> 
> Neither "band of origination" nor "antenna pointing vector" information
> appears to be contained in the suggestion above...

The "XX" in the GRID format above is for ICON and OVERLAY character.  I
would assign your FREQ BANDS to ICONS as shown below, and then use the 36
overlay characters for your frequency sub band information...

BANDS FREQS      ICON
----- ---------  ----------------------------
X     3-30  KHz  The diamond
L     30-300Khz  The Lighthouse
M     .3-3  MHz  The tall Radio Antenna
H     3-30  MHz  The existing HF ICON
V     30-300MHz  A VHF Icon (Ill find one)
U     .3-3  GHz  The existing QTH with a Beam
S     3-30  GHz  The existing dish antenna
E     30-300THz  The alternate "E" Icon.

Then not only do your packets contain this detailed info, but they also
visually convey this information at a glance...

You could put the Beam Heading in the SSID. or add one character. (The "Z"
I added above)
But if you reserved the TO_CALL SSID for SSID routing, then you could
actually shorten ALL BeaconNET packets by 7 bytes!  You would be
eliminating the "HOP2-2" bytes entirely (saving 7 bytes) and then use the
SSID (-2) as originally intended for routing.  The disaadvantage of this
is that the KPC-3 does not support SSID routing yet, but  UIview does (or
could).

That is why I hate to mess up SSID routing which you could use in the
future to great advantage by using the SSID now just to save one byte.
So I wouild probably suggest that you add one character for beam
direction. (With the potential of saving 6 in the future)...

bob
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 08:55:42 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id IAA23306
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 08:55:34 -0500 (CDT)
Message-ID: <LYR11589-5604-2001.04.08-09.12.08--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 09:53:45 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Overlooked Interests - Free Bytes? [was:D7/D700 and ALTNET [was:APRS(tm)  Protocol Spec/BEACONet]]
References: <Pine.GSO.4.05L.10104080806180.22788-100000@arctic>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD06D69.C994577F@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> >   - since the BEACONet TO-Call information appears to work on two
> >     major APRS software titles, the discussion turns to the Kenwoods
> 
> Yes, two out of say a dozen?

The interest was to find a software title that would run on most
people's computers, that would meet the interests of the BEACONet
community.  These two titles will take care of 90% of the worlds
computers (DOS and Windows).  I'm not sure of your point...but the
interest is being met.

The next point that you made keyed back in on the use of the "HY"
frequency designator, rather than "CQ".  First...let me say that I'm
giving some serious thought to that...given the potential of embedding
the frequency into the icon overlay (I've got more exploration to do,
though).  But another statement makes me think that you are still
overlooking another BEACONet interest:

> > * There is no frequency-of-origination flag in the APRS protocol
> 
> Each packet has as many free bytes as you want.  One can put 
> anything in any of the free bytes in any APRS packet.  Anyone 
> can decode them to mean anything they want... without violating 
> the spec.  I am all for adding such a designation for this 
> application, but just not in a place that makes the  packets
> non-compliant.

There is a BEACONet interest in assuring the shortest human-readable
frame.  If you are inferring that there are 256 "free bytes" to choose
from, then you are missing the point.

In fact...the *only* "free bytes" that exist in an AX.25 packet frame
are the ones in the To-Field and any unused bytes in path aliases.  All
others consume space.  The *only* "free bytes" in a BEACONet comment
field are the "[ ]" around the grid...and we included them only because
APRSdos requires the "["! (see...there can be concessions <smile>).

Have I missed something?

Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 09:07:16 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id JAA24104
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 09:07:12 -0500 (CDT)
Message-ID: <LYR11589-5605-2001.04.08-09.23.46--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 10:05:20 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: The moving target [was:A BeaconNet idea...]
References: <LYR21978-5596-2001.04.08-08.14.00--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD07020.B6C57A16@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> > Bob is sharing a note with the listserve that he shared with me
> > privately last week -- and I replied to.  I'm saddened that he did so,
> > as I'd have preferred to not air this topic to the list....
> 
> I thought we brought this to the APRSspec list for open discussion?

Actually, I didn't mean to infer any violation of etiquette...no offense
was taken.  I intended to simply say "we've already talked about this
issue and it has been taken into consideration (for further
research)...why is it out there again?"...It's probably simply a
difference of style, nothing more.

I also hope that others don't think this is an adversarial <sp?> thing. 
Nothing could be further from the truth.  I'm committed to the BEACONet
thing, and am endebted to others for their work and to you for your
interest in it.

I'm simply making sure that the interests of the BEACONet community are
addressed in any future modifications, if they are made...that's all.

Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 11:10:21 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id LAA02793
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 11:10:15 -0500 (CDT)
Message-ID: <LYR11589-5622-2001.04.08-11.26.43--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 12:07:55 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] More BEACONet interests [was:The moving target [was:A BeaconNet  idea...]]
References: <LYR21978-5603-2001.04.08-09.05.20--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD08CDB.7A39C6FA@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

I'm going to parrot back what I understand about your suggestion:

> W2EV-xx>CQxxxx,HOP2-2:>GG##ggXX.Z

W2EV-##>CQnpah,HOP2-2:>GG##ggIO.V
     ||   ||||         ||||||||||
     ||   ||||         |||||||||+- Beam Vector-+
     ||   ||||         ||||||||+-- what's this?+--2-bytes for V maybe?
     ||   ||||         |||||||+--- Overlay for the icon (27 needed)
     ||   ||||         ||||||+---- Icon (8 needed)
     ||   ||||         ++++++----- 6-character grid
     ||   |||+-- H.A.A.T.
     ||   ||+--- Antenna Contribution (element count or dBd)
     ||   |+---- Power Output (1mW to 32MW)
     ||   +----- Network Personality (Digi, Bridge, Gate, etc)
     ++--------- SSID to allow for multiple occurances of same call

Now...to be clear...your suggestion wastes three bytes entirely:
CQ conveys nothing of use to BEACONet
TO-Call -SSID goes unused...but is still transmitted as a byte.

I like the icon idea, but there is another interest being driven here,
too.  Because BEACONet is a "network sniffer for UI networks" it is just
as important to know the network personality visually, as it is to know
the band of origination.  Since "n" exists in the BEACONet protocol, it
was hoped to use that as the driver for the Icon, rather than frequency
of operation.  I'm going to play with the icon idea a bit to see what I
get (there may be another variation to the theme that could work).

In case anyone cares..."n" is described in the BEACONet protocol
specification on the website: http://go.to/BEACONet | Information |
Protocol.

Other issues still remain.  I've spelled them out in other eMails and
would be interested in your thoughts on addressing them as part of the
package.

By the way...SSID routing is useless to BEACONet...WIDEn-N doesn't allow
the tracing that we really need.  There is no advantage to is...it will
always be a wasted byte.

Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 15:15:36 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA18892
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 15:15:34 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 16:15:24 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: Other BEACONet interests to factor [was:D7/D700 and ALTNET [was:APRS(tm)  Protocol]]
In-Reply-To: <LYR11586-5602-2001.04.08-08.54.26--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5653-2001.04.08-15.32.10--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104081603070.28954-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sun, 8 Apr 2001, Ev Tupis wrote:

> BEACONet enjoys an alias called RFONLY...
> In taking BEACONet out of the ALTNET world something else happens:
> * RFONLY becomes an issue because now all other APRS programs can
>   decode a BEACONet frame...and they don't recognize the RFONLY
>   alias
> 
> The astute observer will have two comments:
>     "No one can guarantee that some third party won't IGate a 
>      signal anyway, even with the alias"
>     "It's not the contesters' fault if someone else relays the
>      information"

This is a good point.  But I am a little confused.

If the non-standard ALTNET construct allows you to be isolated from any
other inadvertant APRS software from IGATING your packets, then that would
seem to be sufficient in itself to solve the problem of RFONLY routing.
So why then is the RFONLY alias needed?  (I do think RFONLY alias is also
a very good idea too.)

Does this mean that all BEACONet packets have the RFONLY alias in them at
the cost of 7 bytes per packet?

You do have a very valid point about not wanting conventional APRS
software in use by a non-fully-understanding user to link your BEACONet
packets worldwide back to RF...  Lemme think about that some....  I'd
like to find a single bit somewhere that can do that much more
efficiently...

Lemme think about this...

bob
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 15:36:54 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA19961
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 15:36:50 -0500 (CDT)
Message-ID: <LYR11589-5659-2001.04.08-15.53.26--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 16:34:59 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: Other BEACONet interests to factor [was:D7/D700 and  ALTNET [was:APRS(tm)  Protocol]]
References: <LYR21978-5653-2001.04.08-15.32.10--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD0CB73.8A37232A@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> > BEACONet enjoys an alias called RFONLY...
> > In taking BEACONet out of the ALTNET world something else happens:
> > * RFONLY becomes an issue because now all other APRS programs can
> >   decode a BEACONet frame...and they don't recognize the RFONLY
> >   alias
> >
> > The astute observer will have two comments:
> >     "No one can guarantee that some third party won't IGate a
> >      signal anyway, even with the alias"
> >     "It's not the contesters' fault if someone else relays the
> >      information"
> 
> This is a good point.  But I am a little confused.

RFONLY is invoked only by stations that are engaged in VHF Contests. 
Otherwise, "24/7" BEACONet stations may launch frames with either HOPn-N
or nothing.  RFONLY is an option to satisfy the needs of the
Contesting/DX Chasing BEACONet community, not a reqirement for all
BEACONet-ers.

Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 15:52:44 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA21116
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 15:52:39 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 16:52:24 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: More BEACONet interests [was:The moving target [was:A BeaconNet  idea...]]
In-Reply-To: <LYR11586-5622-2001.04.08-11.26.43--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5680-2001.04.08-16.09.14--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104081625530.28954-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>

On Sun, 8 Apr 2001, Ev Tupis wrote:

> By the way...SSID routing is useless to BEACONet...WIDEn-N doesn't allow
> the tracing that we really need.  There is no advantage to is...it will
> always be a wasted byte.

Hummh... conversly, I am beginning to see it as a neat future
for BEACONet.   Here is how:

1)  Using -n instead of HOPn-N saves 7 bytes in every single packet
2)  This does not need to be a WIDEn-N implementatin. On BEACONet, you
    can define that all such -n packets will be digipeated as TRACEn
    so that they include their path.
3)  Since UIview uses KISS mode, ROger could code this into UIvew
    overnight.  ALso, since the UIDIGI firmware also supports SSID
    routing, I am sure that its author would be happy to also make this
    possible.  UI-DIGI roms will fit in any of the millions of old TAPR-2
    CLONES.  ALso, any old 286 PC with any TNC and DIGI-NED software 
    also supports SSID routing...
4)  We can also include the RFONLY flag in a single bit.  Here's how:

SSID ROUTING FOR BEACON NET:

   if SSID is 0 then no digipeating
   if SSID is 1 to N then digipeat and add digipeaters MYCALL (TRACEn)
   if SSID is 10 to 1N then subtract 10 and digipeat as above
      but consider this packet as an RFONLY packet.

Thus BEACONet can save 7 bytes in every packet,
It retains an RFONLY flag
It retains a TRACEn-N mechanism
It LEADS the APRS community in using this valuable routing method
It will allow TAPR-2 CLONE TNC's using UI-DIGI firmware to be used
   for beacon net without the expense of KPC-3's for everyone...

This would be a long term goal.  It sort of depends on how many Beaconnet
users use KPC-3's, how manuy use TAPR-2 clones, and how many use UIVIEW?
I admit it would be a transition, but until the transition was complete,
then HOPn-N could continue to be used... and still be compatible.

Actually it saves 14 bytes if you cnosider that you no longer need the
RFONLY alias either...

Bob
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 16:39:54 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA23027
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 16:39:51 -0500 (CDT)
Message-ID: <LYR11589-5692-2001.04.08-16.56.26--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 17:37:58 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: More BEACONet interests [was:The moving target [was:A  BeaconNet  idea...]]
References: <LYR21978-5680-2001.04.08-16.09.14--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD0DA36.DFEAA45@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> > By the way...SSID routing is useless to BEACONet...WIDEn-N 
> > doesn't allow the tracing that we really need.  There is no 
> > advantage to is...it will always be a wasted byte.
> 
> Hummh... conversly, I am beginning to see it as a neat future
> for BEACONet.   Here is how:
> 
> 1)  Using -n instead of HOPn-N saves 7 bytes in every single packet
> 2)  This does not need to be a WIDEn-N implementatin.

But Bob...the APRS Protocol Specification (page 26 of 128) expressly
says that ToCall SSID routing is WIDEn-N and WIDE.  You're not proposing
that BEACONet deliberately tool-up in opposition to the spec, are you?
;-)

Chuckling just a little,
Ev
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 16:52:42 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA23767
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 16:52:38 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 17:52:28 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: More BEACONet interests [was:The moving target [was:A  BeaconNet  idea...]]
In-Reply-To: <LYR11586-5692-2001.04.08-16.56.26--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5693-2001.04.08-17.09.14--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104081749370.777-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sun, 8 Apr 2001, Ev Tupis wrote:

> > Hummh... conversly, I am beginning to see it as a neat future
> > for BEACONet.   Here is how:
> > 
> > 1)  Using -n instead of HOPn-N saves 7 bytes in every single packet
> > 2)  This does not need to be a WIDEn-N implementatin.
> 
> But Bob...the APRS Protocol Specification (page 26 of 128) expressly
> says that ToCall SSID routing is WIDEn-N and WIDE.  You're not proposing
> that BEACONet deliberately tool-up in opposition to the spec, are you?
> ;-)

I thought you might noctice that.  But the difference is that these
packets are still decodable by everyone.  This modification to what is in
the spec is a non-exclusive "enhancement".  In ANY WIDEn-N digi, it has
alwasys been a SYSOP perogative to enable path tracing in a closed net if
he likes...
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 17:03:02 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id RAA24866
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 17:03:00 -0500 (CDT)
Message-ID: <LYR11589-5694-2001.04.08-17.19.31--lyris.aprsspec#tapr.org@lists.tapr.org>
From: kbrown@powerhouseproductions.com (Kevin Brown)
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
References: <LYR22300-5693-2001.04.08-17.09.14--kbrown#powerhouseproductions.com@lists.tapr.org>
Subject: [aprsspec] More BEACONet interests [was:The moving target [was:A  BeaconNet  idea...]]
Date: Sun, 8 Apr 2001 16:59:47 -0500
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <01f701c0c077$3a3d21e0$08db0ecf@187th.org>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Maybe I'm the only one...but since this thread appears to be between the two
of you...any chance you could actually email one another direct?  I haven't
seen anyone else reply/interject on this subject..
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 17:04:07 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id RAA25433
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 17:04:02 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-5695-2001.04.08-17.20.34--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 18:03:40 -0400
From: Jeff King <jeff@aerodata.net>
Organization: Aero Data Systems, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
CC: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: Other BEACONet interests to factor [was:D7/D700 and   ALTNET [was:APRS(tm)  Protocol]]
References: <LYR21978-5653-2001.04.08-15.32.10--w2ev#rochester.rr.com@lists.tapr.org> <LYR22299-5659-2001.04.08-15.53.26--jeff#aerodata.net@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD0E03C.A5492CE5@aerodata.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk



Ev Tupis wrote:
> 
> > > BEACONet enjoys an alias called RFONLY...
clip
> > This is a good point.  But I am a little confused.
> 
> RFONLY is invoked only by stations that are engaged in VHF Contests.

FYI, AFILTER and I believe UI-View both support "NOGATE" already which
effectively does the same thing. (keeps the RF gateway from sending
the frame on to the internet).
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 17:37:27 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id RAA28887
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 17:37:21 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Sun, 8 Apr 2001 18:37:10 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: More BEACONet interests [was:The moving target [was:A  BeaconNet  idea...]]
In-Reply-To: <LYR11586-5694-2001.04.08-17.19.31--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-5698-2001.04.08-17.53.58--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104081834030.1526-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

On Sun, 8 Apr 2001, Kevin Brown wrote:

> Maybe I'm the only one...but since this thread appears to be between the two
> of you...any chance you could actually email one another direct?  I haven't
> seen anyone else reply/interject on this subject..

Interesting.  Ev was acused of developing BEACONet protocols without open
public discussion of the protocol and thus it evolved as non APRS
compatible.  He brought it here to have a public discussion of how
BEACONet can or cannot fit into the APRS protocol.  I thought that was
what this list was for?

Just hit DEL key if you are disinterested...

Bob
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 19:11:45 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id TAA04977
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 19:11:42 -0500 (CDT)
Date: Sun, 8 Apr 2001 19:11:27 -0500
Message-Id: <LYR11589-5713-2001.04.08-19.28.14--lyris.aprsspec#tapr.org@lists.tapr.org>
From: "James Jefferson" <jjeffers@deskmedia.com>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] NMEA 0183 checksum spec
X-IPAddress: 206.9.220.135
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <200104090011.TAA31189@dm.deskmedia.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Can someone please point me in the direction of a document describing
the NMEA 0183 checksum and how it is calculated? Sample code?

-James Jefferson


---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 20:50:35 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id UAA09675
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 20:50:31 -0500 (CDT)
Date: Sun, 8 Apr 2001 20:50:24 -0500
Message-Id: <LYR11589-5719-2001.04.08-21.07.09--lyris.aprsspec#tapr.org@lists.tapr.org>
From: "James Jefferson" <jjeffers@deskmedia.com>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Here's how NMEA 0183 checksum is calculated
X-IPAddress: 206.9.220.135
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <200104090150.UAA06493@dm.deskmedia.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

(from Garmin's website - and verified by numerous other sources)
Q. How is the checksum calculated in NMEA 0183?

A. The checksum is the 8-bit exclusive OR (no start or stop bits) of all
characters in the sentence, including the "," delimiters, between -- but
not including -- the "$" and "*" delimiters. 

The hexadecimal value of the most significant and least significant 4
bits of the result are converted to two ASCII characters (0-9, A-F) for
transmission. The most significant character is transmitted first
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From bounce-aprsspec-11589@lists.tapr.org  Sun Apr  8 21:37:25 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id VAA12801
	for <lyris.aprsspec@tapr.org>; Sun, 8 Apr 2001 21:37:23 -0500 (CDT)
Message-ID: <LYR11589-5724-2001.04.08-21.53.52--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sun, 08 Apr 2001 22:35:15 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Cause and Effect...from the Horses Mouth
References: <LYR21978-5698-2001.04.08-17.53.58--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD11FE3.81BC9E4F@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> Interesting.  Ev was acused of developing BEACONet protocols 
> without open public discussion of the protocol and thus it 
> evolved as non APRS compatible.  He brought it here to have 
> a public discussion of how BEACONet can or cannot fit into 
> the APRS protocol.  I thought that was what this list was for?
> 
> Just hit DEL key if you are disinterested...

* The BEACONet protocol was opened to public scrutiny on TAPR's
  PropNET/BEACONet listserve.  It was also discussed with Bob B.
  during development.  It has never been "without open public
  discussion".  Check the list archives.  The topic is there.

* Since the "Cause" is inaccurate, how can the "effect" of "thus it
  evolved as non APRS compatible" be defended?  Never the less, it
  was said ...
  - From an APRS perspective (which is what this seems to be), the
    BEACONet system operates as an ALTNET (to the letter of the APRS
    protocol spec).  Ok...so maybe it's a *bunch* of ALTNET's, but it
    *is* fully compliant with the spec on ALTNETs.

* I brought the discussion here because I wanted to clear the general
  APRS listserve of it (it had nothing to do with general APRS).  I
  never said that it was here to see how it "can or cannot fit into
  the APRS protocol".

Now...for a recap of the thread up to this point...this discussion was
engaged because Kenwood radios don't have a function to disable ALTNET
filters...therefore BEACONet was proclaimed by Bob as "non APRS
compatible".

A secondary discussion ensued as to how to reformat the BEACONet frame
to allow Kenwood to decode them...but then the tables turned.  Bob found
out that APRS(tm) protocols, network topologies and procedures were not
BEACONet(tm) compatible (I *hate* when that happens).  :o)

Bob's giving this further thought.

I think that pretty much sums it up so far. :o)  This thread can
continue on or off list...it makes no nevermind to me.  I'm learning
some good things to *maybe* incorporate in the next revision of the
BEACONet protocol spec and lurking folks are being given an insight into
APRS's cousin that thay may not have previously had.

And again for the record...there is no personal affront intended by me
nor taken by me with any of this discussion.  The BEACONet concept was
based on experimentation...that's what we're doing.  A year from now,
the experiment may be over and all that may be left is my satisfaction
of "doing" rather than "dreaming"...then again... :o))

Ev
http://go.to/BEACONet
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From bounce-aprsspec-11589@lists.tapr.org  Mon Apr  9 06:03:05 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id GAA26089
	for <lyris.aprsspec@tapr.org>; Mon, 9 Apr 2001 06:03:00 -0500 (CDT)
Message-ID: <LYR11589-5794-2001.04.09-06.19.37--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Mon, 09 Apr 2001 07:01:07 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Non-exclusive Enhancement? [was: More BEACONet interests [was:The moving  target [was:A  BeaconNet  idea...]]]
References: <LYR21978-5693-2001.04.08-17.09.14--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD19673.403E5817@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

After suggesting that TOCALL SSID routing be setup to use TRACEn-N
instead of WIDEn-N and Wide, Bob Bruninga wrote:

> > But Bob...the APRS Protocol Specification (page 26 of 128) 
> > expressly says that ToCall SSID routing is WIDEn-N and WIDE.  
> > You're not proposing that BEACONet deliberately tool-up in 
> > opposition to the spec, are you?  ;-)
> 
> I thought you might noctice that.  But the difference is that 
> these packets are still decodable by everyone.  This modification 
> to what is in the spec is a non-exclusive "enhancement".  In ANY 
> WIDEn-N digi, it has alwasys been a SYSOP perogative to enable 
> path tracing in a closed net if he likes...

I've searched the APRS Protocol Specification on the key words of
"exclusive", "enhance" and "modif"ication and come up dry.  Where can I
get more information on the topic of "modifications that are allowed
because they are considered non-exclusive enhancementes"?

Ev

---
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From bounce-aprsspec-11589@lists.tapr.org  Mon Apr  9 20:38:15 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id UAA29756
	for <lyris.aprsspec@tapr.org>; Mon, 9 Apr 2001 20:38:14 -0500 (CDT)
Message-ID: <LYR11589-5930-2001.04.09-20.54.51--lyris.aprsspec#tapr.org@lists.tapr.org>
From: "Sadowski, Allan" <allan.sadowski@ncshp.org>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: More BEACONet interests [was:The moving target	 [was:A  BeaconNet  idea...]]
Date: Mon, 9 Apr 2001 21:42:26 -0400 
MIME-Version: 1.0
Content-Type: text/plain
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <BF01BF9F0651D311B7A100104B716B9001A94903@SHPMAIL>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

I for one... want to see this kind of exchange  ... especially since it
involves APRS SPEC... if I get a vote.. I say EV and Bob... please
continue...  Each exchange furthers my knowledge about the spec.....

ALOHA
AH6LS

> Maybe I'm the only one...but since this thread appears to be between the
> two
> > of you...any chance you could actually email one another direct?  I
> haven't
> > seen anyone else reply/interject on this subject..
> 
> 

---
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From bounce-aprsspec-11589@lists.tapr.org  Wed Apr 11 15:17:16 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id PAA12612
	for <lyris.aprsspec@tapr.org>; Wed, 11 Apr 2001 15:17:07 -0500 (CDT)
Mime-Version: 1.0
X-Sender: mcmusick@mail.anet-stl.com
Message-Id: <LYR11589-6309-2001.04.11-15.33.46--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Wed, 11 Apr 2001 14:50:53 -0500
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: Mike Musick <mcmusick@anet-stl.com>
Subject: [aprsspec] From APRSSIG - proposal for modified object format
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <p04310101b6fa644aade1@[207.206.136.32]>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Recap: Jeff Brenton suggested that we look at a way to create objects 
that expire. This week's rash of springtime storms underscored a 
serious need for self-deleting objects to automatically clear the 
display of obsolete, superceded or otherwise out-of-date objects.

The proposed protocol consists of adding a expiration time to the 
comments field, like so:

   ;CELL1    *092345z4903.50N\07201.75W[088/036/EXP=0090

This, of course, says that the CELL1 wall cloud object moving east at 
36 Knots expires 90 minutes after 2345z on the 9th. Field is in 
minutes and must have all four digits; "9999" minutes is 81 minutes 
shy of one week, so this gives us a good practical range.

The user interface default value should be relatively short - 30 to 
60 minutes is a good start for discussion. There is no default in the 
on-air packet - the value is always specific. "/EXP=0000" is 
immediate expiration and is illegal; an object with no expiration 
should not have the /EXP= parameter.

This has maximum backwards compatibility (i.e., doesn't break 
anything) and is human-readable when it isn't supported by the 
receiving program.

By expressing the time as a time-out value rather than an end time 
means a lot less work for the parser. We've already parsed the 
092345z, so the expire day and time is simply 092345z + 90 minutes.


What we need now is to hear from anyone who might think of a 
compatibility problem we haven't seen yet so we can get hopefully get 
quick agreement to "just do it".

   ...mike/N0QBF
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From bounce-aprsspec-11589@lists.tapr.org  Wed Apr 11 16:00:17 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA14390
	for <lyris.aprsspec@tapr.org>; Wed, 11 Apr 2001 16:00:14 -0500 (CDT)
Message-Id: <LYR11589-6325-2001.04.11-16.16.51--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Wed, 11 Apr 2001 16:01:27 -0500
From: "Rich Beckwith" <Rich@dps.state.mo.us>
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] [aprssig] Re: From APRSSIG - proposal for modified	object format
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <sad47fe6.078@dps.state.mo.us>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by tapr.org id QAA14390

Is it necessary to have "/EXP="?  I don't believe anything else uses 4 zeros "0000" so you may be able to tack it on the back 088/036/0000 of the report.   It appears the other extensions use 3 zeros "000" at this location i.e. bearing/number/range/quality.  Check for a "0" instead of a "/".

On the other hand "/EXP=" is pretty easy to search for.

What about "/E=" which is similar in format to the "/A=" parameter for altitude?

Rich - Wn0x




---
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From bounce-aprsspec-11589@lists.tapr.org  Wed Apr 11 16:07:57 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA15621
	for <lyris.aprsspec@tapr.org>; Wed, 11 Apr 2001 16:07:56 -0500 (CDT)
Mime-Version: 1.0
X-Sender: mcmusick@mail.anet-stl.com
Message-Id: <LYR11589-6331-2001.04.11-16.24.40--lyris.aprsspec#tapr.org@lists.tapr.org>
In-Reply-To: <Pine.GSO.4.05L.10104111624040.28551-100000@arctic>
References: <Pine.GSO.4.05L.10104111624040.28551-100000@arctic>
Date: Wed, 11 Apr 2001 16:08:24 -0500
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: Mike Musick <mcmusick@anet-stl.com>
Subject: [aprsspec] Re: From APRSSIG - proposal for modified object format
Cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <p04310102b6fa77f34c8f@[207.206.137.24]>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

At 4:24 PM -0400 4/11/01, Bob Bruninga wrote:

>Only remaining question is whether the /EXP= is floating.  I assume so.
>and all 5 of those charactetrs must be an exact match...

Unless there's a really pressing reason not to, I'd answer "yes".

   ...mike
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From bounce-aprsspec-11589@lists.tapr.org  Thu Apr 12 01:48:03 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id BAA02143
	for <lyris.aprsspec@tapr.org>; Thu, 12 Apr 2001 01:48:00 -0500 (CDT)
Date: Thu, 12 Apr 2001 1:47:39
Subject: [aprsspec] Re: [aprssig] Re: From APRSSIG - proposal for modified	object format
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: "Jeff Brenton" <ka9vnv@dididahdahdidit.com>
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
Sender: bounce-aprsspec-11589@lists.tapr.org
Message-Id: <LYR11589-6423-2001.04.12-02.04.39--lyris.aprsspec#tapr.org@lists.tapr.org>
Precedence: bulk

> what about "/E="

Short, consistent, to the point...

And "/E=xxxx" leaves two extra characters for the comment field.
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From bounce-aprsspec-11589@lists.tapr.org  Thu Apr 12 02:47:40 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id CAA05416
	for <lyris.aprsspec@tapr.org>; Thu, 12 Apr 2001 02:47:39 -0500 (CDT)
Message-ID: <LYR11589-6425-2001.04.12-03.04.18--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Thu, 12 Apr 2001 08:46:40 +0100
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: Ian Wade <ian.wade@netro.co.uk>
Reply-To: Ian Wade <wadei@ntlworld.com>
Subject: [aprsspec] Re: [aprssig] Re: From APRSSIG - proposal for modified object format
References: <LYR23375-6423-2001.04.12-02.04.39--ian.wade#netro.co.uk@lists.tapr.org>
In-Reply-To: <LYR23375-6423-2001.04.12-02.04.39--ian.wade#netro.co.uk@lists.tapr.org>
MIME-Version: 1.0
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <$cEyWjAg1V16EwOm@netro.co.uk>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

In article <LYR23375-6423-2001.04.12-02.04.39--ian.wade#netro.co.uk@list
s.tapr.org>, Jeff Brenton <ka9vnv@dididahdahdidit.com> writes
>> what about "/E="
>
>Short, consistent, to the point...
>
>And "/E=xxxx" leaves two extra characters for the comment field.


And two fewer characters liable to corruption. (And you don't really
need the "=" either).

The shorter the packet the better.

-- 
73
Ian, G3NRW
g3nrw@tapr.org
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From bounce-aprsspec-11589@lists.tapr.org  Thu Apr 12 07:12:19 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id HAA25345
	for <lyris.aprsspec@tapr.org>; Thu, 12 Apr 2001 07:12:15 -0500 (CDT)
From: Rolf Bleher <mail@Rolf-Bleher.de>
Reply-To: mail@Rolf-Bleher.de
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: From APRSSIG - proposal for modified object format
Date: Thu, 12 Apr 2001 14:10:51 +0200
Content-Type: text/plain;
  charset="iso-8859-1"
MIME-Version: 1.0
Message-Id: <LYR11589-6447-2001.04.12-07.29.02--lyris.aprsspec#tapr.org@lists.tapr.org>
Content-Transfer-Encoding: 8bit
X-Sender: 320093807643-0001@t-dialin.net
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <01041214105103.01164@terra>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk


> >Only remaining question is whether the /EXP= is floating.  I assume so.
> >and all 5 of those charactetrs must be an exact match...
> 
> Unless there's a really pressing reason not to, I'd answer "yes"

I think it's a good solution, but why not using
   /D=1234   for duration 1234 minutes, or
   /X=1234   for expires in 1234 minutes

It's a little bit shorter...

Rolf
-- 
                                _______________________________________
  Rolf Bleher       DK7IN      /
  N52d32.660' E013d20.920'    /  Linux - life is too short for reboots
_____________________________/             http://www.Rolf-Bleher.de
                                              mail@Rolf-Bleher.de
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From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 12:32:31 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA29652
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 12:32:28 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-6705-2001.04.13-12.49.07--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 13:31:40 -0400
From: Jeff King <jeff@aerodata.net>
Organization: Aero Data Systems, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD737FC.F3DD2468@aerodata.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Bill:

I'm copying this to APRSSPEC as well since some of the APRS authors there are already
discussing it.

I believe Bob's algorithm was based on picking a second of the minute to beacon on. It
was seeded with your callsign. He would have posted it a few weeks before Dayton, not
sure if it was last year or the year before. This required no changes to anyones software,
it just required you to set the clock on your computer or sending device.

Coordinated time slots would be best as you suggested, but it requires a internet connection. We
actually discussed this before.... the way you solve it is to have two granulates
for the devices beaconing. You can pack the devices on the internet second by second
where as the mobile devices you assign in a different segment (as far away (in time) as
possible).

Basically, the mobile devices could send in the last 30 seconds of the minute, where
as the internet connected devices could send in the first 30 seconds. You'll still
have some collisions (as it is only a 50/50 chance the mobile will have his time set
correctly to hit that last 30 seconds) but at least it will help somewhat.

Also, what will help alot is to STOP beaconing the first time you see your packet
repeated. You could calculate sat rise and sat set, and only beacon until you are
heard during each interval. A server could handle this as well.

-Jeff



Bill Diaz wrote:
> 
> Don't recall the algorithm Bob described.
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From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 12:39:49 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA00354
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 12:39:47 -0500 (CDT)
Message-ID: <LYR11589-6710-2001.04.13-12.56.32--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 13:37:44 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net> <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD73968.345488C7@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

> I believe Bob's algorithm was based on picking a second of the 
> minute to beacon on.

Wouldn't that infer one-minute beaconing through the ISS?  I was under
the impression that folks were attempting to avoid that if possible.

Ev, W2EV
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You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 12:53:44 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA01365
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 12:53:41 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-6719-2001.04.13-13.10.06--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 13:52:49 -0400
From: Jeff King <jeff@aerodata.net>
Organization: Aero Data Systems, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
CC: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net> <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org> <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD73CF1.A8D63BBB@aerodata.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk



Ev Tupis wrote:
> 
> > I believe Bob's algorithm was based on picking a second of the
> > minute to beacon on.
> 
> Wouldn't that infer one-minute beaconing through the ISS?  I was under
> the impression that folks were attempting to avoid that if possible.

No. Second of the chosen minute. Could be once a minute, 
or once every 10 minutes. Lacking a centralized slot server, you need a 
universal random method to chose the second of the minute to send on as
well as beacon frequency, whatever it might be for ISS.

In any case, I'm not telling anyone how to do anything. Don't have any
interest myself in beaconing through ISS. Just recalling a
similar discussion regarding beaconing at Dayton which also delt with
hidden terminals. 

-Jeff












> 
> Ev, W2EV
> 
> ---
> You are currently subscribed to aprsspec as: jeff@aerodata.net
> To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
> Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org

---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 12:57:36 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id MAA01627
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 12:57:33 -0500 (CDT)
Message-ID: <LYR11589-6720-2001.04.13-13.13.11--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 13:53:46 -0400
From: Ev Tupis <w2ev@rochester.rr.com>
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net> <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org> <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org> <3AD73CF1.A8D63BBB@aerodata.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD73D2A.D51A5B80@rochester.rr.com>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Jeff King wrote:
> 
> Ev Tupis wrote:
> >
> > > I believe Bob's algorithm was based on picking a second of the
> > > minute to beacon on.
> >
> > Wouldn't that infer one-minute beaconing through the ISS?  I was under
> > the impression that folks were attempting to avoid that if possible.
> 
> No. Second of the chosen minute.

Ahh. I misunderstood.  Thanks.

Regards,
Ev

---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 13:11:50 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id NAA02821
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 13:11:49 -0500 (CDT)
Message-Id: <LYR11589-6724-2001.04.13-13.28.24--lyris.aprsspec#tapr.org@lists.tapr.org>
X-Sender: dvanhorn@mail.cedar.net
Date: Fri, 13 Apr 2001 13:11:08 -0500
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: David VanHorn <dvanhorn@cedar.net>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
In-Reply-To: <LYR11608-6719-2001.04.13-13.10.06--dvanhorn#cedar.net@list
 s.tapr.org>
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
 <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
 <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <4.3.2.7.2.20010413130919.00aecf00@mail.cedar.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk


>
>No. Second of the chosen minute. Could be once a minute,
>or once every 10 minutes. Lacking a centralized slot server, you need a 
>universal random method to chose the second of the minute to send on as 
>well as beacon frequency, whatever it might be for ISS.

How is this different, in a practical sense, from just turning on a 
transmitter with a fixed beacon rate, at some arbitrary time?

What happens if I'm sharing a "slot" with an alligator?




--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9



---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 16:19:44 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA17635
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 16:19:39 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-6756-2001.04.13-16.36.28--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 17:19:27 -0400
From: Jeff King <jeff@aerodata.net>
Organization: Aero Data Systems, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
CC: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
	 <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
	 <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org> <LYR22299-6724-2001.04.13-13.28.24--jeff#aerodata.net@lists.tapr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD76D5F.FC77A37A@aerodata.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

Dave:

David VanHorn wrote:
> 
> >
> >No. Second of the chosen minute. Could be once a minute,
> >or once every 10 minutes. Lacking a centralized slot server, you need a
> >universal random method to chose the second of the minute to send on as
> >well as beacon frequency, whatever it might be for ISS.
> 
> How is this different, in a practical sense, from just turning on a
> transmitter with a fixed beacon rate, at some arbitrary time?

It is no different. Yet explain to me, lacking any formal specification, how you
would insure that this in indeed arbitrary? Humans are not random, and
the point of the posting I referenced to was some human pseudo code for
insuring this randomness. I believe the callsign was used as the random
seed (for the slot that the beacon occurred in) and some beacon rate was
pre-agreed upon.

The point here, is that if you assume humans are random, when it comes to numbers,
you'll end up with bunching. They are not random.


> What happens if I'm sharing a "slot" with an alligator?

I begin to wonder when someone asks a question they already know the answer to, 
in particular when they are not an attorney. Of course it won't
work if someone decides to ignore the rules of the road. If you think what I was
suggesting won't work, just say that. It won't hurt my feelings in particular since
it wasn't even my idea (although I do agree it is a good idea, your pessimism may
be closer to reality).

My only reason for posting was to mention Bob B. had came up with a pseudo 
algorithm some years back for the Dayton Hamfest. It *might* apply here. Because
the search engine on the TAPR Lyris site is broken, I was unable to post a
link to the message.

-Jeff

---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 16:47:28 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id QAA19727
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 16:47:24 -0500 (CDT)
X-Authentication-Warning: arctic.usna.edu: bruninga owned process doing -bs
Date: Fri, 13 Apr 2001 17:47:12 -0400 (EDT)
From: Bob Bruninga <bruninga@usna.edu>
X-Sender: bruninga@arctic
cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
In-Reply-To: <LYR11586-6756-2001.04.13-16.36.28--bruninga#nadn.navy.mil@lists.tapr.org>
Message-ID: <LYR11589-6763-2001.04.13-17.04.12--lyris.aprsspec#tapr.org@lists.tapr.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <Pine.GSO.4.05L.10104131722560.15255-100000@arctic>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>

Another answer might have been that sharing a slot with an aligator is
not that bad.  Even if he has 10 dB more power (500 to your 50w) then at
many times through the pass due to all the other variables going on,
soooner or later, you are going to be 10 dB stronger and he is going to be
10 dB worse.  Bingo, you get in...

> > What happens if I'm sharing a "slot" with an alligator? > 

Jeff wrote:
> I begin to wonder when someone asks a question they already know the
> answer to,  in particular when they are not an attorney. Of course it
> won't work if someone decides to ignore the rules of the road. If you
> think what I was suggesting it won't work, just say that. It won't hurt
> my feelings in particular since it wasn't even my idea (although I do
> agree it is a good idea, your pessimism may be closer to reality).
> -Jeff


---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 19:31:01 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id TAA00193
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 19:31:00 -0500 (CDT)
Message-Id: <LYR11589-6790-2001.04.13-19.47.46--lyris.aprsspec#tapr.org@lists.tapr.org>
X-Sender: dvanhorn@mail.cedar.net
Date: Fri, 13 Apr 2001 19:15:52 -0500
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: David VanHorn <dvanhorn@cedar.net>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
Cc: APRS Spec Discussion List <aprsspec@lists.tapr.org>
In-Reply-To: <LYR11608-6756-2001.04.13-16.36.28--dvanhorn#cedar.net@list
 s.tapr.org>
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
 <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
 <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org>
 <LYR22299-6724-2001.04.13-13.28.24--jeff#aerodata.net@lists.tapr.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <4.3.2.7.2.20010413190511.02fb17d0@mail.cedar.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk


>
>It is no different. Yet explain to me, lacking any formal specification, 
>how you
>would insure that this in indeed arbitrary? Humans are not random, and the 
>point of the posting I referenced to was some human pseudo code for 
>insuring this randomness.

Algorithms aren't random either.
The best you can approach is "difficult to predict", and "evenly 
distributed".


>The point here, is that if you assume humans are random, when it comes to 
>numbers,
>you'll end up with bunching. They are not random.
>
>
> > What happens if I'm sharing a "slot" with an alligator?
>
>I begin to wonder when someone asks a question they already know the answer to

I was wondering if anyone had implemented/suggested a method to handle that.




--
Dave's Engineering Page: http://www.dvanhorn.org
Where's dave? http://www.findu.com/cgi-bin/find.cgi?kc6ete-9



---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Fri Apr 13 20:07:31 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id UAA03393
	for <lyris.aprsspec@tapr.org>; Fri, 13 Apr 2001 20:07:31 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-6799-2001.04.13-20.24.12--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Fri, 13 Apr 2001 21:07:11 -0400
From: Jeff King <jeff@aerodata.net>
Organization: Aero Data Systems, Inc.
X-Accept-Language: en
MIME-Version: 1.0
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
CC: APRS Spec Discussion List <aprsspec@lists.tapr.org>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
	 <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
	 <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org>
	 <LYR22299-6724-2001.04.13-13.28.24--jeff#aerodata.net@lists.tapr.org> <4.3.2.7.2.20010413190511.02fb17d0@mail.cedar.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <3AD7A2BF.58E0FEEC@aerodata.net>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk



David VanHorn wrote:
> 

> >Humans are not random, and the
> >point of the posting I referenced to was some human pseudo code for
> >insuring this randomness.
> 
> Algorithms aren't random either.

No, they are not. That is why you need to chose a seed number that is random.
Maybe use the checksum of your callsign as the seed number (or some combination
of the unique letters in your callsign).

> The best you can approach is "difficult to predict", and "evenly
> distributed".

EXACTLY. Evenly distributed is the key here. Still no where near as good 
as some sort of assigned slotting system, yet better then the bunching and
anarchy when folks are left to their own choices.

> > > What happens if I'm sharing a "slot" with an alligator?

> I was wondering if anyone had implemented/suggested a method to handle that.

The FCC rules define that fairly well. Minimum power needed for communications. 
I would think into a pair of crossed dipoles, 5 watts would be plenty.

It is really hard to enforce morality. If someone runs 500 watts (20db more then
is needed) then all they care about is themselves. I don't have a solution for
that one other then to decline to participate in a RF power war, if that is what it
is becoming. Anyways, ISS is long term so the congestion will clear out in due time
after the novelty factor wears out. Then some useful applications can be deployed.

-Jeff

---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sat Apr 14 03:13:59 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id DAA06292
	for <lyris.aprsspec@tapr.org>; Sat, 14 Apr 2001 03:13:49 -0500 (CDT)
Message-ID: <LYR11589-6854-2001.04.14-03.30.35--lyris.aprsspec#tapr.org@lists.tapr.org>
Date: Sat, 14 Apr 2001 09:13:06 +0100
To: "APRS Spec Discussion List" <aprsspec@lists.tapr.org>
From: Roger Barker <roger@peaksys.co.uk>
Subject: [aprsspec] Re: [aprssig] Re: Hidden transmitters & ARISS
References: <01C0C412.99CEDBA0.billdiaz@megsinet.net>
 <LYR21978-6705-2001.04.13-12.49.07--w2ev#rochester.rr.com@lists.tapr.org>
 <LYR22299-6710-2001.04.13-12.56.32--jeff#aerodata.net@lists.tapr.org>
 <LYR22299-6724-2001.04.13-13.28.24--jeff#aerodata.net@lists.tapr.org>
 <4.3.2.7.2.20010413190511.02fb17d0@mail.cedar.net>
 <LYR13460-6799-2001.04.13-20.24.12--roger#peaksys.co.uk@lists.tapr.org>
In-Reply-To: <LYR13460-6799-2001.04.13-20.24.12--roger#peaksys.co.uk@lists.tapr.org>
MIME-Version: 1.0
List-Unsubscribe: <mailto:leave-aprsspec-11589P@lists.tapr.org>
List-Software: Lyris Server version 3.0
List-Subscribe: <mailto:subscribe-aprsspec@lists.tapr.org>
List-Owner: <mailto:owner-aprsspec@lists.tapr.org>
X-List-Host: Tucson Amateur Packet Radio <http://www.tapr.org>
X-Message-Id: <rtGp1xASaA26Ewnm@peaksys.co.uk>
Sender: bounce-aprsspec-11589@lists.tapr.org
Precedence: bulk

In article <LYR13460-6799-2001.04.13-20.24.12--roger#peaksys.co.uk@lists
.tapr.org>, Jeff King <jeff@aerodata.net> writes
[snip]
>
>EXACTLY. Evenly distributed is the key here. Still no where near as good 
>as some sort of assigned slotting system, yet better then the bunching and
>anarchy when folks are left to their own choices.

What I don't understand in this discussion is why anyone thinks that
bunching of transmissions will occur in the current situation, because
surely anarchy is inherently random? Could someone explain to me the
mechanism that is going to cause the bunching?

As far as I can see, the only advantage of assigned slots would be that
if you say to someone, for example, "transmit on second 37", then you're
also telling them to transmit no more than once a minute.

Also, I'm not so sure that the long periods of silence from ISS are as a
result of it being held off by uplink traffic. If it was, then I would
expect to see it spew out a whole bunch of frames when eventually it got
in, but I haven't seen any evidence of that at all. What I do notice is
that it seems much easier to access it when it's at a very low elevation
than when it's at a high angle, and that certainly isn't because of the
antennas I'm using. Could this be as a result of the position of the 2m
antenna on ISS?

-- 
Roger Barker, G4IDE - roger@peaksys.co.uk
For UI-View go to - http://www.packetradio.org.uk
For WinPack go to - http://www.peaksys.co.uk

---
You are currently subscribed to aprsspec as: lyris.aprsspec@tapr.org
To unsubscribe send a blank email to leave-aprsspec-11589P@lists.tapr.org
Questions regarding the SIG go to the SIG administrator: wa1lou@tapr.org


From bounce-aprsspec-11589@lists.tapr.org  Sat Apr 14 14:28:52 2001
Received: from lists.tapr.org (lists.tapr.org [204.17.217.24])
	by tapr.org (8.9.3/8.9.3/1.13) with SMTP id OAA00325
	for <lyris.aprsspec@tapr.org>; Sat, 14 Apr 2001 14:28:52 -0500 (CDT)
Errors-To: <jeff@aerodata.net>
Message-ID: <LYR11589-6911-2001.04.14-14.45.38--lyris.aprsspec#tapr.org@lists.tapr.org>
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Roger Barker wrote:
> 
> In article <LYR13460-6799-2001.04.13-20.24.12--roger#peaksys.co.uk@lists
> .tapr.org>, Jeff King <jeff@aerodata.net> writes
> [snip]
> >
> >EXACTLY. Evenly distributed is the key here. Still no where near as good
> >as some sort of assigned slotting system, yet better then the bunching and
> >anarchy when folks are left to their own choices.
> 
> What I don't understand in this discussion is why anyone thinks that
> bunching of transmissions will occur in the current situation, because
> surely anarchy is inherently random? Could someone explain to me the
> mechanism that is going to cause the bunching?

I'll try.

Every so called "random number" algorithm, at least the ones I have worked
with in computers, really isn't random. You need a seed number to at least
give it the chance of being random. Bob had suggested the seed number, in
his post some time ago, as being the persons callsign or some combination.

You also need a standard algorithm to plug that random seed number into,
be it a computer algorithm or human pseudo code. The "algorithm" in this
case could define power levels, when to beacon, when a beacon is successful,
how often to beacon, ect. The random element in the last paragraph is to insure 
even distribution of the transmissions.

Bunching is a known human behavior. One can see it in many forms.... the
desire to pick a "round" number, working 9-5, rush hour, bidding on auctions, 
waiting until ISS is about to rise above the horizon to turn the beacon on. 
Doesn't matter the reason, it is just human behavior when most of us are left 
to our own means or lacking any pseudo code (etiquette) to guide us. 

Anarchy is NOT random although in its earliest stages it may appear that way. 
Anarchy means the lack of any central control or group cooperation. However, 
anarchy is not a stable system. As a behavior system, be it human or political, 
it has a very short half life. As it progresses, its behavior becomes less and 
less random as it moves towards a organized system. In the political arena, we
have periods of anarchy, however they typically don't last long. Local
chieftains gain power over the local population due to some power they
might have a monopoly on. Soon after that, further consolidation occurs.
This is born out time and time again in history. 

This same behavior model could be transposed to ham radio. Even though
most radio regulatory bodies in most countries state to use the minimum power
required, sales of HF amplifiers are brisk. The HF DX pile-ups are a good
example of local chieftains rising to power. The station with the biggest
antenna and biggest amplifier will get the contact. Even though in many cases
the station with 10 watts and a dipole easily could make the contact, they
are unable to compete against the powerhouse station. 

In ISS we could have the same situation. Certain stations could beacon once
every 10 seconds. Certain stations could run 500 watts when 5 watts would
work. The stations that can afford 500 watt amps and don't see a problem
with frequency beacons become the local "chieftain". To compete against the
chieftain, you have to raise your power level and/or your beacon rate. Lacking
any psedo-code, we have a anarchical system. A true anarchical system is unstable, 
hence local chieftains will arise. 

With some assurance of random distribution, and some rules of the road, access
would be more equitable. It also would approach the Aloha model (and with
bunching it is less then aloha). Looking at Dave Vanhorn's example, with the
500 watt station on his 5 watt slot.... you also could dither each slot randomly
within a certain window (although that would require software, up until now everything
I spoke of didn't). 

>As far as I can see, the only advantage of assigned slots would be that
>if you say to someone, for example, "transmit on second 37", then you're
>also telling them to transmit no more than once a minute.

I was primarily discussing means to encourage random distribution as opposed
to a coordinated slotting method. This would require cooperation among the
authors. However, if such is the case, their are significant advantages to
slotted aloha over aloha. I suggest you review some of the texts on packet radio
as you will clearly see the advantages, in particular for systems that are
comprised primarily of hidden terminals.

But lets take what you said a step further. The "only" advantage you state,
one of being able to assign slots and times, into itself is a significant advantage.
But you can take it even further then that. Since this "assignment" is made by
a server that has access to all these stations, and their receivers, it can tell
the sending station when in fact it has been heard by ISS. Then, it can instruct
the sending station... OK, ISS heard you, stop beaconing until ISS is at the other
end of the pass. This then opens up the slot for another station.

>Also, I'm not so sure that the long periods of silence from ISS are as a
>result of it being held off by uplink traffic. If it was, then I would
>expect to see it spew out a whole bunch of frames when eventually it got
>in, but I haven't seen any evidence of that at all.

I'd expect it to be operating in "FULLDUP" mode, that is ignoring CSMA. But
maybe it is not. Your question is best directed towards the ISS team.

>What I do notice is
>that it seems much easier to access it when it's at a very low elevation
>than when it's at a high angle, and that certainly isn't because of the
>antennas I'm using.

What kind of antennas are you using? Most (all) amateur omni antennas direct
most of the signal at the horizon. The best kind of antenna to us for ISS should
be crossed dipoles over a screen. This would give you the best signal as it went
overhead, where as a omni would give you the worst signal overhead.


Now in summary, all of my statements regarding packet theory (and the oversights)
where known by those that designed the ISS digipeater. Everything could have been
addressed before launch. It apparent wasn't. Hence, I don't expect anything
to change. It is primarily a PR tool, and as such, it is targeted exactly right. The
good news here is the novelty will soon wear off, and possibly we can use it for some
limited useful things.

I think rehashing Bob's Dayton psedo-code (Bob?) might be useful as it can be used by
mobiles, but a worldwide slotting system, while a good thing, just wouldn't be that
useful due to the fact it would not be universally adopted. 

-Jeff
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In article <3AD8A4DA.A754F84F@aerodata.net>, Jeff King
<jeff@aerodata.net> writes
>
>I'll try.
[snip]

Thanks for the interesting reply. Perhaps I should make the point that I
was specifically commenting on the concept that "bunching" of
transmission is likely to be currently occurring. To expand the concept,
what it would mean is that -

At any given moment there are 'n' hams within the footprint of ISS
attempting to access it, and some mechanism is causing the transmissions
from those 'n' hams to "bunch" in time rather than be evenly
distributed.

I'm afraid that I'll remain sceptical about that until someone comes up
with a believable "for instance" that could cause it to occur.

>Bunching is a known human behavior. One can see it in many forms.... the
>desire to pick a "round" number, working 9-5, rush hour, bidding on auctions, 
>waiting until ISS is about to rise above the horizon to turn the beacon on. 

But that varies for each ham in the footprint, because they don't all
live in the same place. They also don't all have the same horizon angle,
the same antennas, the same receiver sensitivity, accurate clocks, etc,
etc.

[snip]

>>Also, I'm not so sure that the long periods of silence from ISS are as a
>>result of it being held off by uplink traffic. If it was, then I would
>>expect to see it spew out a whole bunch of frames when eventually it got
>>in, but I haven't seen any evidence of that at all.
>
>I'd expect it to be operating in "FULLDUP" mode, that is ignoring CSMA. But
>maybe it is not. Your question is best directed towards the ISS team.

Given that the TNC reset - hence the NOCALL - my assumption is that it's
operating half duplex. Perhaps I'm wrong?

>>What I do notice is
>>that it seems much easier to access it when it's at a very low elevation
>>than when it's at a high angle, and that certainly isn't because of the
>>antennas I'm using.
>
>What kind of antennas are you using? Most (all) amateur omni antennas direct
>most of the signal at the horizon. The best kind of antenna to us for ISS 
>should
>be crossed dipoles over a screen. This would give you the best signal as it 
>went
>overhead, where as a omni would give you the worst signal overhead.

Circularly polarised crossed dipoles with reflectors underneath (wx sat
style), colinear and a circularly polarised beam. However, I'm not
specifically commenting on my own attempts to access the digi, my
observations are based very much on what I'm hearing of other stations
attempts. (Note - I'm making these comments because I find the subject
interesting, I hope no-one regards it as a complaint or criticism!)

It could of course be that the ISS receiver is being totally blocked by
in band or out of band traffic. It certainly gives the impression that
it is hearing very little. For instance, I've noticed that if a station
connects to ISS (NOCALL), and the TNC on ISS gets in a situation where
it's polling the connected station, the poll frames will be transmitted
every few seconds, which doesn't suggest that it's a simple case of
being held off by uplink traffic.

-- 
Roger Barker, G4IDE - roger@peaksys.co.uk
For UI-View go to - http://www.packetradio.org.uk
For WinPack go to - http://www.peaksys.co.uk
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Roger Barker wrote:
> 
> In article <3AD8A4DA.A754F84F@aerodata.net>, Jeff King
> <jeff@aerodata.net> writes
>
[snip on bunching]

I'm stating bunching is part of human nature. We are not random creatures. While I
will concede to you that outside random influences can mitigate the effects of
bunching, I don't think we should depend on them nor assume such is the case. Someday
everyone's clock may infact be accurate for example. You can't depend on deficiencies
to always exist.

In any case, bunching is just one piece of the puzzle. The idea is to have a standard
algorithm that everyone can use... be it human pseudo code or some computer program.
Doesn't matter. Lacking this, it is in fact anarchy, and the rules of anarchy begin
to take affect. CQ contest, CQ contest.



> >What kind of antennas are you using? 

> Circularly polarised crossed dipoles with reflectors underneath (wx sat
> style), colinear and a circularly polarised beam. 

And is it safe to say you are in the minority here? Most of the ones commenting
on using ISS I have seen are using conventional vertically polarized omni's.

> However, I'm not
> specifically commenting on my own attempts to access the digi, my

Which means your observations are entirely consistent.

Let me ask you this. I was talking with another fellow off SIG and he indicated
to me he was observing some deep fading with the ISS station. He was using a
3.5db gain vertical on his car. With your crossed dipoles, where you observing
any deep fading? (>20db) I suggested that ISS is using linear polarization as
opposed to circular polarization, which is the norm for space coms. In your
case, using circular polarization, your fades would be minimal. Is such the
case?


> It could of course be that the ISS receiver is being totally blocked by
> in band or out of band traffic. It certainly gives the impression that
> it is hearing very little. For instance, I've noticed that if a station
> connects to ISS (NOCALL), and the TNC on ISS gets in a situation where
> it's polling the connected station, the poll frames will be transmitted
> every few seconds, which doesn't suggest that it's a simple case of
> being held off by uplink traffic.


Actually, a thought just came to me. Since ISS is receiving and transmitting on
different frequencies, there is no need to hold off for anything and
it should be in FULLDUP mode.

73

Jeff
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> Actually, a thought just came to me. Since ISS is receiving and
transmitting on
> different frequencies, there is no need to hold off for anything and
> it should be in FULLDUP mode.

They don't have duplexers up there, Jeff! There would be considerable
desense of the receiver in doing that, even if they had two antennas.

-Jim Jefferson KB0THN
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> Subject: [aprsspec] Re: APRS Compliance
> Date: Wed, 28 Mar 2001 07:04:34 -0500
> From: Steve Dimse <k4hg@tapr.org>
> 
> On 3/27/01 5:50 PM Timothy J Salo (tjs@tc.umn.edu) wrote:
> 	[...]
> >I believe that it is far more appropriate for an APRS protocol test suite
> >to be expressed as raw AX.25 frames (which reflect the objective of the
> >protocol specification, namely to specify correct on-the-air formats and
> >protocols).
> >
> To the best of my knowledge, all APRS programs accept the text format of 
> input.

Pic-E, MIC-E, and HamHUD-III come to mind as APRS end-stations that do not
assume the existence of a TNC, and therefore do not accept TNC-style
text strings as input.

> By "raw AX.25 frames" I presume you are proposing a new file 
> format with just the binary data, correct? TTBOMK, no APRS program 
> accepts this format. Therefore, in order to use the test suite, each 
> author must add code to their program, code which is otherwise worthless, 
> and could be another source of errors.

I assume that all APRS programs accept 1200 bps AFSK, either baseband
(e.g., similar to what you would expect out of an audio jack on your
rig) or RF.

> Alternatively, someone must write 
> programs to transmit the info on the air (or two TNC's back to back). 
> This would allow people other than the programmers to perform the test, 
> but requires setting up hardware.

I believe that making it easy to create and run tests against APRS
software will be a good thing for the APRS community.  I believe that
it will lead to a much greater number of tests being developed and run.
This will lead to a greater understanding of how the different programs
respond to various packets and how the programs compare to the APRS
specification.  It may even lead to an overall improvement in the
APRS implementations.

Obviously, the hardware part isn't very hard.

Somewhere, I have a Java class that represents an AX.25 packet.  It
can create an instance of itself from a TAPR TNC2 or AEA/Timewave
text string, (or, in pre-object-oriented language, it can take a
text string as input).  The class can output itself as a binary string
or a TNC2 or AEA/Timewave text string.  This class is pretty liberal;
it accepts almost anything that is close, even some of the combined
TNC2/AEA format packets found on the APRServe data stream.

It wouldn't be too hard for the class to output itself as a KISS string.
I will probably do this in the next few weeks for another project.

More importantly, this isn't really hard code.  The difficult part is
correctly parsing all the variations in TNC strings, particularly if you
want to use the APRServe data stream as input.  As you mentioned,
many APRS programs have this code already (although I suppose the source
code for many of these implementation is not freely available).

> If it were a TNC text file, click open and you are testing. 
> 
> What precisly do you gain by using this format other than being more pure?

First, TAPR TNC2 text strings are not adequately expressive.  Some
valid APRS packets cannot be encoded using TAPR TNC2 text strings
(e.g., may result in non-printing characters which may or may not be
preserved).  The TNC text format doesn't allow some of the AX.25
fields to be set (e.g., AX.25 reserved bits).  I don't think the
TAPR TNC2 format allows the AX.25 command/response bit to be controlled,
although I think the AEA/Timewave format does.

Second, I believe a language for representing APRS test messages
should also be able to create invalid messages.  A reasonable example
is APRS messages without a terminating CR.  I don't believe these can
be created using TNC text strings, but I believe that messages of this
form used to cause one or more APRS programs to crash.

Third, I believe that anything that continues to promote the TNC model
at this point in history is a disservice to the digital amateur community.
TNCs were instrumental in the popularization of packet radio.  However,
that was a very long time ago -- we shouldn't be thinking in terms
of an architecture that made sense for C-64s.

Finally, I am trying to answer the question: Ignoring other practical
considerations, what would be the most powerful method of representing
APRS packets for the purposes of creating test scripts?

I suppose you can call my proposal more precise, more expressive, more
correct, more modern, or even more pure.  

-tjs
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James:

The FULLDUP ON command just tells the TNC to ignore the Data Carrier
detect signal. Might be a different command for other TNC's, but that
was what my TNC2 was. Doesn't mean you really are full duplex.

-Jeff


James Jefferson wrote:
> 
> > Actually, a thought just came to me. Since ISS is receiving and
> transmitting on
> > different frequencies, there is no need to hold off for anything and
> > it should be in FULLDUP mode.
> 
> They don't have duplexers up there, Jeff! There would be considerable
> desense of the receiver in doing that, even if they had two antennas.
> 
> -Jim Jefferson KB0THN
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On 4/14/01 7:10 PM Timothy J Salo (tjs@tc.umn.edu) wrote:

>> To the best of my knowledge, all APRS programs accept the text format of 
>> input.
>
>Pic-E, MIC-E, and HamHUD-III come to mind as APRS end-stations that do not
>assume the existence of a TNC, and therefore do not accept TNC-style
>text strings as input.
>
The Mic-E does not accept any input, and there are only a couple of 
rarely used Pic-E programs that use the demod fundtion of the Pic-E. The 
HH-III will 
>> By "raw AX.25 frames" I presume you are proposing a new file 
>> format with just the binary data, correct? TTBOMK, no APRS program 
>> accepts this format. Therefore, in order to use the test suite, each 
>> author must add code to their program, code which is otherwise worthless, 
>> and could be another source of errors.
>
>I assume that all APRS programs accept 1200 bps AFSK, either baseband
>(e.g., similar to what you would expect out of an audio jack on your
>rig) or RF.
>
Wrong. None of my programs accept AFSK, and in fact for javAPRS and findu 
there is no way to connect a TNC directly, so the data would have to come 
through another program first. Nor do most of the client programs take 
audio directly, requiring a TNC or sound card to convert the AFSK into 
text or KISS frames first.

>> Alternatively, someone must write 
>> programs to transmit the info on the air (or two TNC's back to back). 
>> This would allow people other than the programmers to perform the test, 
>> but requires setting up hardware.
>
>I believe that making it easy to create and run tests against APRS
>software will be a good thing for the APRS community.  I believe that
>it will lead to a much greater number of tests being developed and run.
>This will lead to a greater understanding of how the different programs
>respond to various packets and how the programs compare to the APRS
>specification.  It may even lead to an overall improvement in the
>APRS implementations.
>
I agree. That is why I think it is important to have a test suite 
available to the largest number of users with the least possible effort.
>...
>More importantly, this isn't really hard code.  The difficult part is
>correctly parsing all the variations in TNC strings, particularly if you
>want to use the APRServe data stream as input.  As you mentioned,
>many APRS programs have this code already (although I suppose the source
>code for many of these implementation is not freely available).
>
No it isn't hard. However, you seem to be advocating multiple back and 
forth conversions before the data actual gets to the program's parser, 
which increases the chance for error. KISS!

>> If it were a TNC text file, click open and you are testing. 
>> 
>> What precisly do you gain by using this format other than being more pure?
>
>First, TAPR TNC2 text strings are not adequately expressive.  Some
>valid APRS packets cannot be encoded using TAPR TNC2 text strings
>(e.g., may result in non-printing characters which may or may not be
>preserved).  The TNC text format doesn't allow some of the AX.25
>fields to be set (e.g., AX.25 reserved bits).  I don't think the
>TAPR TNC2 format allows the AX.25 command/response bit to be controlled,
>although I think the AEA/Timewave format does.
>
Setting undefined bits is hardly something that needs to be part of the 
tesing suite. If someone defines a bit that the AX-25 protocol reserves, 
it is simply not a valid AX-25 packet!

Non-printing characters can be present in a text string, in fact they are 
all the time. There are only a handful allowed in the spec, and none of 
these are ones that even require escaping (normally ctrl-v) like return.

>Second, I believe a language for representing APRS test messages
>should also be able to create invalid messages.  A reasonable example
>is APRS messages without a terminating CR.  I don't believe these can
>be created using TNC text strings, but I believe that messages of this
>form used to cause one or more APRS programs to crash.
>

Most APRS packets are transmitted on the air without a trailing carriage 
return. If you want to include one in the string, you must escape it, 
e.g. <ctl-v><cr>

>Third, I believe that anything that continues to promote the TNC model
>at this point in history is a disservice to the digital amateur community.
>TNCs were instrumental in the popularization of packet radio.  However,
>that was a very long time ago -- we shouldn't be thinking in terms
>of an architecture that made sense for C-64s.
>
Version 1 of the aprsspec is, and alway we be, heavily dependent on the 
TNC model. We are talking about the test suite for version 1 of the spec. 
If there ever is a version 2, and it is not dependent on the TNC model, 
then your argument makes sense.

>Finally, I am trying to answer the question: Ignoring other practical
>considerations, what would be the most powerful method of representing
>APRS packets for the purposes of creating test scripts?
>
One that can be looked at and examined by eye, without the need for 
editing software. You didn't address this point of my argument. How 
exactly do you plan to create and edit these packets?

As I said, you can use a vanilla binhex editor, but then everyone 
writing, editing, and even just looking at them needs to become fluent 
with the ins and outs of AX-25. You could write an AX-25 specific editor, 
but you'd need at least Mac, Windows, and Linux versions for it to be 
available to all who would be interested, and even then some knowledge of 
the AX-25 spec would be needed.

>I suppose you can call my proposal more precise, more expressive, more
>correct, more modern, or even more pure.  
>
No, I wouldn't, I'd say it's more effort-intensive, and more error prone.

Steve K4HG
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.
Once again I have been handed the utterly impossible task of covering all 
of APRS in 45 minutes within the TAPR Digital Forum on Friday. Without 
announcement I have already received four requests for time. In previous 
years, I tried to do a "What's New" sort of presentation myself, but this 
year I will let people speak for themselves...here are the ground rules:

1. Anyone that wants to talk should email me directly (k4hg@tapr.org) 
with a request, giving presenter's name, callsign, and topic. The 
deadline for requests will be 0000z on May 5th. NO EXCEPTIONS!

2. Given that the requests already total more than the allocated 45 
minutes, time will be split evenly among all who request. If any 
presentations run short, there will be a general Q&A period afterwards. 
NO EXCEPTIONS!

3. Given the problems that usually occur when trying to connect laptops 
to the projector at presentations, no computers will be allowed. If you 
have something you want to show off, create a handout to be passed out 
prior to the presentation. NO EXCEPTIONS!

4. I will be very strict about time, I will notify the speakers in 
advance of the time per presentation. Time will start from when you are 
announced, not when you get to the front and start talking, so get there 
early and sit in front if you want to maximize your time. I suggest you 
practice to get it all in within your allocated time. NO EXCEPTIONS!

5. No yielding of allocated time (I.e. don't bother getting 5 of your 
buddies to request time so you can talk longer). NO EXCEPTIONS!

6. If you ask for time, and then can't make it, please let me know as 
soon as possible so that I can adjust the schedule.

7.  It would good to announce where you will be later in the day for 
questions, since there will be little if any time for questions to be 
fielded at the time.

Sorry for the rules, but this is hard enough to do in a 6 hour format at 
the DCC, 45 minutes is really tough.

I'd like a volunteer or two to help distribute handouts so we can 
minimize disruptions.

Steve K4HG

[Please forward this to any APRS-related lists I miss]
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